[enumification] support "non-constant-to-constant" transition in enums too. #1080
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s too. At 9a73c4c we became much more precise about enumification, because formerly we only pull int constant information through DroidDoc only in the latest API. Besides, we had been precise on which int fields are final and which aren't, in API XML metadata. Since we switched the information source to API XML metadata, such final fields that were NOT final are strictly converted to enums only in the constant-ified API Level. That was regarded as regression at dotnet#1078 . The solution to this situation is: treat them as constants. To do so, now generate-const-list-2.cs is changed to NOT check if an int field is final or not, until at the merge phase. Then we filter out those non-constant fields (which are not much). This uncovers those "formerly non constant" fields too. Fortunately such fields didn't exist other than the ones at PR dotnet#1078 mentioned (this generate-const-list-2.exe now prints out such fields now.)
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Apr 18, 2020
Changes: xamarin/monodroid@8466972...16cb1cb * xamarin/monodroid@16cb1cb1a: Bump to xamarin/androidtools@068e4f5 (dotnet#1084) * xamarin/monodroid@8f61f0cae: Bump to xamarin/android-sdk-installer@d9276b4 (dotnet#1085) * xamarin/monodroid@bec720cd0: Bump to xamarin/jar2xml@4125da65 (dotnet#1083) * xamarin/monodroid@a49e901d6: [tools/msbuild] update <BuildApk/> task inputs (dotnet#1082) * xamarin/monodroid@b9f16c002: Bump to xamarin/androidtools@5412dc8 (dotnet#1081) * xamarin/monodroid@673a74961: [.NET 5] fix for ALC isolation between assemblies (dotnet#1080)
jonpryor
added a commit
that referenced
this pull request
Apr 19, 2020
Changes: xamarin/monodroid@8466972...16cb1cb * xamarin/monodroid@16cb1cb1a: Bump to xamarin/androidtools@068e4f5 (#1084) * xamarin/monodroid@8f61f0cae: Bump to xamarin/android-sdk-installer@d9276b4 (#1085) * xamarin/monodroid@bec720cd0: Bump to xamarin/jar2xml@4125da65 (#1083) * xamarin/monodroid@a49e901d6: [tools/msbuild] update <BuildApk/> task inputs (#1082) * xamarin/monodroid@b9f16c002: Bump to xamarin/androidtools@5412dc8 (#1081) * xamarin/monodroid@673a74961: [.NET 5] fix for ALC isolation between assemblies (#1080)
jonpryor
added a commit
that referenced
this pull request
Apr 23, 2020
Changes: xamarin/monodroid@70a1164...d35c422 * xamarin/monodroid@d35c4221b: Bump to xamarin/jar2xml@4125da65 (#1083) * xamarin/monodroid@ea68087b0: [tools/msbuild] update <BuildApk/> task inputs (#1082) * xamarin/monodroid@16c2eb29e: Bump to xamarin/androidtools@fba677c4 (#1081) * xamarin/monodroid@53abd4f03: [.NET 5] fix for ALC isolation between assemblies (#1080)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At 9a73c4c we became much more precise about enumification, because
formerly we only pull int constant information through DroidDoc only in
the latest API.
Besides, we had been precise on which int fields are final and which aren't,
in API XML metadata.
Since we switched the information source to API XML metadata, such final
fields that were NOT final are strictly converted to enums only in the
constant-ified API Level.
That was regarded as regression at #1078 .
The solution to this situation is: treat them as constants.
To do so, now generate-const-list-2.cs is changed to NOT check if an int
field is final or not, until at the merge phase. Then we filter out those
non-constant fields (which are not much).
This uncovers those "formerly non constant" fields too. Fortunately such
fields didn't exist other than the ones at PR #1078 mentioned (this
generate-const-list-2.exe now prints out such fields now.)